Technologies for establishing secure channel between i/o subsystem and trusted application for secure i/o data transfer

ABSTRACT

Technologies for secure I/O data transfer includes a compute device, which includes a processor to execute a trusted application, an input/output (I/O) device, and an I/O subsystem. The I/O subsystem is configured to establish a secured channel between the I/O subsystem and a trusted application running on the compute device, and receive, in response to an establishment of the secured channel, I/O data from the I/O device via an unsecured channel. The I/O subsystem is further configured to encrypt, in response to a receipt of the I/O data, the I/O data using a security key associated with the trusted application that is to process the I/O data and transmit the encrypted I/O data to the trusted application via the secured channel, wherein the secured channel has a data transfer rate that is higher than a data transfer rate of the unsecured channel between the I/O device and the I/O subsystem.

CLAIM TO PRIORITY

This application is a continuation of and claims the benefit of andpriority to U.S. application Ser. No. 16/369,303, entitled TECHNOLOGIESFOR ESTABLISHING SECURE CHANNEL BETWEEN I/O SUBSYSTEM AND TRUSTEDAPPLICATION FOR SECURE I/O DATA TRANSFER, by Reshma Lal, et al., filedMar. 29, 2019, the entire contents of which are incorporated herein byreference.

BACKGROUND

Input data from an input/output (I/O) device to a software applicationof a system may have high security sensitivity and need to be protectedfrom being stolen by a rogue application in the system. For example, adigital assistant may capture user's voice by an I/O device (e.g.,microphone), which may have privacy sensitivity information and mayrequire or preferred to be protected as the voice data gets transferredfrom the I/O device to an application running inside a trusted executionenvironment (TEE). In some cases, a digital assistant provider may optfor a service model in which a device or software running on the devicemay be offered by multiple third-party vendors. This may increase anumber of vendors and the software, which is not necessarily trusted bythe user, that the user has to trust to access the privacy sensitivityinformation. Additionally, in order to perform a secure I/O with theTEE, the TEE may authenticate and verify the identity of the I/O device.However, not all I/O devices have encryption capability to encrypt I/Odata to enable security.

BRIEF DESCRIPTION OF THE DRAWINGS

The concepts described herein are illustrated by way of example and notby way of limitation in the accompanying figures. For simplicity andclarity of illustration, elements illustrated in the figures are notnecessarily drawn to scale. Where considered appropriate, referencelabels have been repeated among the figures to indicate corresponding oranalogous elements.

FIG. 1 is a simplified block diagram of at least one embodiment of acompute device having an I/O subsystem for establishing a securedchannel for a secure I/O data transfer;

FIG. 2 is a simplified block diagram of at least one embodiment of anenvironment of the I/O subsystem of FIG. 1 ;

FIGS. 3 and 4 are a simplified flow diagram of at least one embodimentof a method for performing a secure I/O data transfer between the I/Osubsystem and a trusted application running on a host processor of thecompute device of FIG. 1 that may be executed by the I/O subsystem ofthe compute device of FIGS. 1 and 2 ; and

FIG. 5 is a simplified block diagram of at least one embodiment of amethod for supporting full duplex communication channels between an I/Odevice and the I/O subsystem and between the I/O subsystem and the hostprocessor of the compute device of FIG. 1 .

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific embodiments thereof havebeen shown by way of example in the drawings and will be describedherein in detail. It should be understood, however, that there is nointent to limit the concepts of the present disclosure to the particularforms disclosed, but on the contrary, the intention is to cover allmodifications, equivalents, and alternatives consistent with the presentdisclosure and the appended claims.

References in the specification to “one embodiment,” “an embodiment,”“an illustrative embodiment,” etc., indicate that the embodimentdescribed may include a particular feature, structure, orcharacteristic, but every embodiment may or may not necessarily includethat particular feature, structure, or characteristic. Moreover, suchphrases are not necessarily referring to the same embodiment. Further,when a particular feature, structure, or characteristic is described inconnection with an embodiment, it is submitted that it is within theknowledge of one skilled in the art to effect such feature, structure,or characteristic in connection with other embodiments whether or notexplicitly described. Additionally, it should be appreciated that itemsincluded in a list in the form of “at least one A, B, and C” can mean(A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).Similarly, items listed in the form of “at least one of A, B, or C” canmean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, inhardware, firmware, software, or any combination thereof. The disclosedembodiments may also be implemented as instructions carried by or storedon a transitory or non-transitory machine-readable (e.g.,computer-readable) storage medium, which may be read and executed by oneor more processors. A machine-readable storage medium may be embodied asany storage device, mechanism, or other physical structure for storingor transmitting information in a form readable by a machine (e.g., avolatile or non-volatile memory, a media disc, or other media device).

In the drawings, some structural or method features may be shown inspecific arrangements and/or orderings. However, it should beappreciated that such specific arrangements and/or orderings may not berequired. Rather, in some embodiments, such features may be arranged ina different manner and/or order than shown in the illustrative figures.Additionally, the inclusion of a structural or method feature in aparticular figure is not meant to imply that such feature is required inall embodiments and, in some embodiments, may not be included or may becombined with other features.

Referring now to FIG. 1 , a compute device 100 for establishing asecured channel for a secure I/O data transfer with a trustedapplication running on the compute device 100 includes a processor 120,an I/O subsystem 126, and one or more I/O devices 138. In use, asdescribed further below, the I/O subsystem 126 may establish a securedchannel between an application running inside a trusted executionenvironment (TEE) of the host processor 120 (e.g., a trusted application124) and the I/O subsystem 126 for a secure I/O data transfer. To do so,the I/O subsystem 126 may establish a secured channel between the I/Osubsystem and the trusted application 124. To do so, the I/O subsystem126 may receive a security key that is shared with the trustedapplication 124 to be used to communicate with the trusted application124. For example, in the illustrative embodiment, the I/O subsystem 126may be configured by a basic input output system (BIOS) with thesecurity key, which is securely shared with the trusted application 124.It should be appreciated that, although a single trusted application isshown in FIG. 1 , there may be multiple trusted applications inside atrusted execution environment (TEE) of the host processor 120. In such acase, a secured channel is established between each trusted applicationand the I/O subsystem 126 using a respective security key that is sharedbetween the corresponding trusted application and the I/O subsystem 126.

Additionally, the I/O subsystem 126 may further configure the securedchannel based on configuration data received from the trustedapplication 124 via the established secured channel. For example, theconfiguration data may define initialization parameter, such as, but notlimited to, a packet size, a header size, a header format, a format ofdata packets, and/or a flow control information, for I/O data that is tobe transferred from the I/O subsystem 126 to the trusted application124. In some embodiments, the configuration of the secured channel mayrequire a power reset. In such embodiments, the interposer securitylogic unit 128 may configure the secured channel upon a power reset.

Once the secured channel is established, the I/O subsystem 126 mayreceive I/O data, from an I/O device 138 via an unsecured channel, thatis to be transferred to and processed by the trusted application 124. Inresponse to receiving the I/O data, the I/O subsystem 126 may encryptthe I/O data using the security key that is shared with the trustedapplication 124 and transferred the encrypted I/O data to the trustedapplication 124 via the secured channel. It should be appreciated that,in the illustrative embodiment, a data transfer rate of the securedchannel is faster than a data transfer rate of the unsecured channelbetween the I/O device and the I/O subsystem to account for encryptiondelays. As such, the secured channel established between the I/Osubsystem 126 and the trusted application 124 may provide I/O dataprotection without implementing hardware or software modifications toI/O devices 138.

The compute device 100 may be embodied as any type of device capable ofperforming the functions described herein. For example, the computedevice 100 may be embodied as, without limitation, a computer, a server,a workstation, a laptop computer, a tablet computer, a notebookcomputer, a mobile computing device, a smartphone, a wearable computingdevice, a multiprocessor system, and/or a consumer electronic device. Asshown in FIG. 1 , the illustrative compute device 100 includes theprocessor 120, the I/O subsystem 126, a memory 132, and a data storagedevice 134. Additionally, in some embodiments, one or more of theillustrative components may be incorporated in, or otherwise form aportion of, another component. For example, the memory 132, or portionsthereof, may be incorporated in the processor 120 in some embodiments.

The processor 120 may be embodied as any type of processor capable ofperforming the functions described herein. For example, the processor120 may be embodied as a single or multi-core processor(s), digitalsignal processor, microcontroller, or other processor orprocessing/controlling circuit. As shown, the processor 120illustratively includes secure enclave support 122, which allows theprocessor 120 to establish a trusted execution environment (TEE) knownas a secure enclave, in which executing code may be measured, verified,and/or otherwise determined to be authentic. Additionally, code and dataincluded in the secure enclave may be encrypted or otherwise protectedfrom being accessed by code executing outside of the secure enclave. Forexample, code and data included in the secure enclave may be protectedby hardware protection mechanisms of the processor 120 while beingexecuted or while being stored in certain protected cache memory of theprocessor 120. The code and data included in the secure enclave may beencrypted when stored in a shared cache or the main memory 132. Thesecure enclave support 122 may be embodied as a set of processorinstruction extensions that allows the processor 120 to establish one ormore secure enclaves in the memory 132. For example, the secure enclavesupport 122 may be embodied as Intel® Software Guard Extensions (SGX)technology. As such, in the illustrative embodiment, applications thatare running in the secure enclave 122 are considered trustedapplications (e.g., the trusted application 124).

The memory 132 may be embodied as any type of volatile or non-volatilememory or data storage capable of performing the functions describedherein. In operation, the memory 132 may store various data and softwareused during operation of the compute device 100 such as operatingsystems, applications, programs, libraries, and drivers. As shown, thememory 132 is coupled to the processor 120 and/or the I/O subsystem 126via a multi-key total memory encryption engine (MKTME) 130, which may beincluded in or otherwise coupled to a memory controller, integratedmemory controller hub, or other memory interface. The MKTME 130 allowsthe compute device 100 to transparently encrypt the contents of thememory 132. The MKTME 130 maintains a table or other internal, protectedstructure with multiple encryption keys, which are used to encrypt anddecrypt data as it is stored to and read from the memory 132,respectively. The encryption keys are illustratively 128-bit AES XTSkeys although may be embodied as any symmetric, asymmetric, or otherencryption key. The encryption key may be selected by the MKTME 130 on aper-page basis, for example based on a key identifier included in one ormore otherwise unused upper bits of the physical memory page address fora particular memory access. In those embodiments, an operating system,virtual memory monitor, or other supervisory component of the computedevice 100 may control access to particular memory pages by configuringone or more page tables and/or extended page tables with the appropriatekey identifiers. MKTME keys may be generated by the MKTME 130, in whichcase they are not disclosed outside of the SoC, or may be supplied bysoftware. In some embodiments, the MKTME 130 may include support forIntel Trusted Domain Extensions (TDX). With TDX, the MKTME 130 mayaccept an external “domain” key, also called a “user” or “tenant” key.The MKTME 130 may also use a default key that is self-generated toprotect memory used by MKTME and Intel SGX as well as Intel TDX.Although illustrated as coupled between the memory 132 and the processor120 and I/O subsystem 126, it should be understood that in someembodiments, the MKTME 130 may be included in the processor 120, in theI/O subsystem 126, or other component of the compute device 100.

As shown, the processor 120 is communicatively coupled to the I/Osubsystem 126, which may be embodied as circuitry and/or components tofacilitate input/output operations with the processor 120, the memory132, and other components of the compute device 100. For example, theI/O subsystem 126 may be embodied as, or otherwise include, memorycontroller hubs, input/output control hubs, sensor hubs, hostcontrollers, firmware devices, communication links (i.e., point-to-pointlinks, bus links, wires, cables, light guides, printed circuit boardtraces, etc.) and/or other components and subsystems to facilitate theinput/output operations. As shown, the memory 132 may be directlycoupled to the processor 120, for example via an integrated memorycontroller hub. In some embodiments, the memory 132 may be directlycoupled to the processor 110, for example via an integrated memorycontroller hub or a data port. The I/O subsystem 126 may further includea sideband network, secure fabric, or other secure routing support. Thesecure routing support may include hardware support to ensure I/O datacannot be misrouted in the I/O subsystem 126 under the influence ofrogue software. Additionally, in some embodiments, the I/O subsystem 126may form a portion of a system-on-a-chip (SoC) and be incorporated,along with the processor 120, the memory 132, and/or other components ofthe compute device 100, on a single integrated circuit chip.Additionally or alternatively, in some embodiments the processor 120 mayinclude an integrated memory controller and a system agent, which may beembodied as a logic block in which data traffic from processor cores andI/O devices converges before being sent to the memory 132.

As shown, the I/O subsystem 126 further includes an interposer securitylogic unit 128. The interposer security logic unit 128 may be embodiedas any hardware controller(s), component(s), or other circuitry capableof performing the functions described herein. In particular, theinterposer security logic unit 128 is configured to establish a securedchannel between the I/O subsystem and an application running inside atrusted execution environment (TEE) (e.g., the trusted application 124)of the compute device 100. To do so, the interposer security logic unit128 may receive a security key that is shared with the trustedapplication 124 running on the host processor 120. For example, in theillustrative embodiment, the secured channel manager 220 may beconfigured by a basic input output system (BIOS) with the security key,which is securely shared with the trusted application 124.

Additionally, the interposer security logic unit 128 may be furtherconfigured to configure the secured channel based on configuration datareceived from the trusted application 124 via the secured channel. Itshould be appreciated that the configuration data is encrypted by thetrusted application 124 using the security key that is shared betweenthe trusted application 124 and the interposer security logic unit 128.The configuration data defines initialization parameter, such as, butnot limited to, a packet size, a header size, a header format, a formatof data packets, and/or a flow control information, for I/O data that isto be transferred from the I/O subsystem 126 to the trusted application124. In response to a receipt of the encrypted configuration data, theinterposer security logic unit 128 may decrypt the configuration datausing the security key and configure the secured channel based on theconfiguration data. In some embodiments, the configuration of thesecured channel may require a power reset. In such embodiments, theinterposer security logic unit 128 may configure the secured channelupon a power reset.

Once the secured channel is established, the interposer security logicunit 128 is configured to receive I/O data that is to be transferred toand processed by a trusted application 124. In response to receiving theI/O data, the interposer security logic unit 128 is further configuredto encrypt the I/O data using the security key that is shared with thetrusted application 124 and transfer the encrypted I/O data to thetrusted application 124 via the corresponding secured channelestablished between the interposer security logic unit 128 and thetrusted application 124. In the illustrative embodiment, the interposersecurity logic unit 128 may be embodied as a field-programmable gatearray (FPGA). It should be appreciated that, in some embodiments, theinterposer security logic unit may be incorporated along the I/O pathfrom the I/O device 138 to the processor 120.

The data storage device 134 may be embodied as any type of device ordevices configured for short-term or long-term storage of data such as,for example, memory devices and circuits, memory cards, hard diskdrives, solid-state drives, non-volatile flash memory, or other datastorage devices. The compute device 100 also includes the communicationsubsystem 136, which may be embodied as any communication circuit,device, or collection thereof, capable of enabling communicationsbetween the compute device 100 and other remote devices over a computernetwork (not shown). The communication subsystem 136 may be embodied asany network interface card, network adapter, network controller, hostfabric interface, network coprocessor, or other component that connectsthe compute device 100 to a computer network. The communicationsubsystem 136 may be configured to use any one or more communicationtechnology (e.g., wired or wireless communications) and associatedprotocols (e.g., Ethernet, InfiniBand®, Bluetooth®, Wi-Fi®, WiMAX, 3G,4G LTE, etc.) to effect such communication. In some embodiments, thecommunication subsystem 136 may form a portion of an SoC and beincorporated along with the processor 120, the memory 132, the I/Osubsystem 126, and/or other components of the compute device 100 on asingle integrated circuit chip.

The I/O device 138 may be embodied as an I/O device of the computedevice 100 that generates I/O data that may be transferred to anapplication running on the host processor 120. For example, in someembodiments, the I/O device 138 may include a touch screen, graphicscircuitry, a graphical processing unit (GPU) and/or processor graphics,an audio device, a microphone, a camera, a keyboard, a mouse, a networkinterface, and/or other input/output devices, endpoints, interfacedevices, and/or peripheral devices. In some embodiments, the I/O device138 may be embodied as an accelerator, which may be embodied as afield-programmable gate array (FPGA), an application-specific integratedcircuit (ASIC), a graphics processor unit (GPU), a coprocessor, or otherdigital logic device capable of performing accelerated functions (e.g.,accelerated application functions, accelerated network functions, orother accelerated functions).

As shown, the compute device 100 may further include one or moreperipheral devices 140. The peripheral devices 140 may include anynumber of additional input/output devices, interface devices, hardwareaccelerators, and/or other peripheral devices. As shown, one or more ofthe peripheral devices 140 may be coupled to the I/O subsystem 126 viacorresponding I/O switches 142. The I/O switches 142 may be embodied asPCI Express (PCIe) switches, PCIe bridges, and/or other switching orrouting components of the computing device 100. Thus, the computingdevice 100 may include a hierarchical system of connected I/O devices,switches, buses, links, and/or other I/O components.

Referring now to FIG. 2 , in an illustrative embodiment, the I/Osubsystem 126 of the compute device 100 establishes an environment 200during operation. The illustrative environment 200 includes an I/Ocommunicator 210, a secured channel manager 220, a data encryptor 230,and an application communicator 240. The various components of theenvironment 200 may be embodied as hardware, firmware, software, or acombination thereof. As such, in some embodiments, one or more of thecomponents of the environment 200 may be embodied as circuitry orcollection of electrical devices (e.g., I/O communicator circuitry 210,secured channel manager circuitry 220, data encryptor circuitry 230,and/or application communicator circuitry 240). It should be appreciatedthat, in such embodiments, one or more of the I/O communicator circuitry210, the secured channel manager circuitry 220, the data encryptorcircuitry 230, and the application communicator circuitry 240 may form aportion of I/O subsystem 126. Additionally, in some embodiments, one ormore of the illustrative components may form a portion of anothercomponent and/or one or more of the illustrative components may beindependent of one another.

The I/O communicator 210 is configured to communicate with one or moreI/O devices 138 to receive I/O data that is to be transferred to andprocessed by an application running on the host processor 120.

The secured channel manager 220 is configured to establish a securedchannel between the I/O subsystem and an application running inside atrusted execution environment (TEE) (e.g., the trusted application 124)of the compute device 100. To do so, the secured channel manager 220 isconfigured to receive a security key that is shared with the trustedapplication 124. For example, in the illustrative embodiment, thesecured channel manager 220 is configured by a basic input output system(BIOS) with the security key, which is securely shared with the trustedapplication 124. Additionally, the secured channel manager 220 isfurther configured to configure the established secured channel. To doso, the secured channel manager 220 receives configuration data that isencrypted using the security key from the trusted application 124 viathe secured channel. For example, the configuration data may defineinitialization parameter, such as, but not limited to, a size of packet,a header size, a header format, a format of data packets, and/or a flowcontrol information, for I/O data that is to be transferred from the I/Osubsystem 126 to the trusted application 124. In response to a receiptof the encrypted configuration data, the secured channel manager 220 isconfigured to decrypt the configuration data and configure the securedchannel based on the configuration data. In some embodiments, theconfiguration of the secured channel may require a power reset. In suchembodiments, the secured channel manager 220 may configure the securedchannel upon a power reset.

The data encryptor 230 is configured to encrypt the I/O data using thesecurity key that is shared with the trusted application 124 that is toprocess the I/O data. As discussed above, the I/O data received from theI/O device 138 is not encrypted and is transferred via an unencryptedchannel.

The application communicator 240 is configured to transmit the encryptedI/O data encrypted by the data encryptor 230 to the trusted application124 via the secured channel. As discussed above, a secured channel isestablished between the I/O subsystem 126 and the trusted application124. The encrypted I/O data is to be decrypted by the trustedapplication 124 using the security key to be processed. As discussedabove, in some embodiments, there may be multiple applications inside atrusted execution environment (TEE) of the host processor 120. In suchembodiments, the application communicator 240 is configured to transmitencrypted I/O data, which is encrypted using a security key that isshared with a corresponding trusted application, to the correspondingtrusted application via a secured channel that is established betweenthe corresponding trusted application and the I/O subsystem 126.

Referring now to FIGS. 3 and 4 , in use, the interposer security logicunit 128 of the I/O subsystem 126 of the compute device 100 may executea method 300 for performing a secure I/O data transfer between the I/Osubsystem and a trusted application 124 running inside a trustedexecution environment (TEE) of the host processor 120 of the computedevice 100 (e.g., the trusted application 124). It should be appreciatedthat, in some embodiments, the operations of the method 300 may beperformed by one or more components of the environment 200 of the I/Osubsystem 126 of the compute device 100 as shown in FIG. 2 . The method300 begins in block 302, in which the interposer security logic unit 128establishes a secured channel between the I/O subsystem 126 and atrusted application 124 running on the host processor 120 of the computedevice 100. To do so, the interposer security logic unit 128 receives asecurity key that is shared with the trusted application 124 running onthe host processor 120, as indicated in block 304. For example, in theillustrative embodiment, a basic input output system (BIOS) configuresthe interposer security logic unit 128 with the security key andsecurely shares the security key with the trusted application 124.However, it should be appreciated that, in other embodiments, theinterposer security logic unit 128 may be configured by any trustedexecution environment (TEE) of the compute device 100.

In block 306, the interposer security logic unit 128 receives encryptedconfiguration data that is encrypted using the security key from thetrusted application 124 via the established secured channel. In someembodiments, the configuration data may define initialization parametersfor an I/O data transferred from an I/O device 138, as indicated inblock 308. For example, the initialization parameters may include, butnot limited to, a size of a packet, a header size, a header format, aformat of data packets, and/or a flow control information of the I/Odata transfer from an I/O device 138. It should be appreciated that theinitialization parameters are not shared with the I/O device 138.

Subsequently, the interposer security logic unit 128 decrypts theencrypted configuration data using the security key in block 310 andconfigures the secured channel based on the configuration data. In someembodiments, the interposer security logic unit 128 may configure thesecured channel upon a power reset.

Once the secured channel is established and configured, the method 300advances to block 316 of FIG. 4 . In block 316, the interposer securitylogic unit 128 receives I/O data from an I/O device 138 that is to betransmitted to and processed by the trusted application 124 running onthe host processor 120. It should be appreciated that the I/O data fromthe I/O device 138 is received via a channel that is not encrypted. Inparticular, the I/O data may be received over a relatively low-speedfull-duplex I/O link, such as a serial peripheral interface (SPI) link.

If the interposer security logic unit 128 determines that I/O data hasnot been received in block 318, the method 300 loops back to block 316to continue waiting for I/O data from an I/O device 138. If, however,the interposer security logic unit 128 determines that I/O data has beenreceived, the method 300 advances to block 320.

In block 320, the interposer security logic unit 128 encrypts thereceived I/O data using the security key associated with the trustedapplication 124 that is to process the I/O data. As discussed above, thesecurity key is shared between the interposer security logic unit 128and the trusted application 124 to encrypt and decrypt the I/O data fora secure I/O data transfer from the I/O device 138.

Subsequently, in block 322, the interposer security logic unit 128transmits the encrypted I/O data to the trusted application 124 runningon the host processor 120 to be decrypted using the security key sharedwith the interposer security logic unit 128. It should be appreciatedthat, in the illustrative embodiment, the secured channel is afull-duplex communication channel and has a faster data transfer ratecompared to the unsecured channel between the I/O device 138 and the I/Osubsystem 126 to account for encryption delays.

Specifically, as shown in FIG. 5 , the interposer security logic unit128 sends a special packet (e.g., S1, S2, . . . Sn) interleaved witheach packet (i.e., encrypted I/O data) indicating additional informationrequired for encryption and full duplex missed data (e.g., by adding aNULL packet, as shown in TABLE 1). As shown in TABLE 1, it should beappreciated that the interposer security logic unit 128 may insert NULLpackets in full-duplex communications with the host trusted application124 to account for encryption delays or latency. Communications betweenthe interposer security logic unit 128 and the I/O device 138 may notinclude any NULL packets, allowing transparent use of existing I/Odevices 138. In response, the host trusted application 124 may use theextra information included the special packet to decrypt the packet.Additionally, the host trusted application 124 may shift receivedpackets (e.g., by deleting NULL packets) and merge the data from S1. Inother words, when the host trusted application 124 receives the TX andRX packet with a delay shift, the host trusted application 124 mayun-shift by deleting NULL RX packets, such that a driver software wouldnot need to be changed.

TABLE 1 Interposer Security Cycle Host Logic Unit I/O Device 1 TX0|NULLNULL|NULL NULL|NULL 2 TX1|NULL TX0|NULL NULL|NULL 3 TX2|NULL TX1|NULLNULL|NULL 4 TX3|NULL TX2|NULL TX0|RX0 5 TX4|NULL TX3|NULL TX1|RX1 6TX5|NULL TX4|RX0 TX2|RX2 7 TX6|RX0 TX5|RX1 TX3|RX3

For example, again referring to TABLE 1, in cycle 1 the host transmitspacket TX0 to the interposer security logic unit 128. As describedabove, packets provided by the trusted host application 124 areencrypted. Thus, the interposer security logic unit 128 starts adecryption process on packet TX0, which in the illustrative embodimentincludes three cycles of latency, for example to receive the packet overan SPI link, perform a cryptographic operation, and transmit the resultover another SPI link. As the decryption process is started, theinterposer security logic unit 128 transmits a NULL packet back over thefull-duplex link to the host. The interposer security logic unit 128also exchanges NULL packets with the I/O device 138 over a full-duplexlink.

Continuing that example, in cycle 2, the host transmits packet TX1 tothe interposer security logic unit 128, and the interposer securitylogic unit 128 transmits a NULL packet back to the host. In cycle 2, theinterposer security logic unit 128 exchanges NULL packets with the I/Odevice 138 over the full-duplex link. This process continues with cycle3.

In cycle 4, the host transmits packet TX3 to the interposer securitylogic unit 128, and the interposer security logic unit 128 transmits aNULL packet back to the host. By cycle 4, the packet TX0 has completedthe decryption process. Thus, in cycle 4 the interposer security logicunit 128 transmits the packet TX0 over the full-duplex link to the I/Odevice 138. The packet TX0 transmitted to the I/O device 138 isencrypted, and in cycle 4 the I/O device 138 transmits a packet RX0 tothe interposer security logic unit 128 over the full-duplex link. Asdescribed above, packets provided by the I/O device 138 are notencrypted. Thus, the interposer security logic unit 128 starts anencryption process on packet RX0, which in the illustrative embodimentincludes three cycles of latency as described above. Note that packetsTX0 and RX0 are exchanged over the full-duplex link with the I/O device138 in the same cycle.

This process of shifting received packets by inserting NULL packetscontinues. The encryption process of packet RX0 is completed by cycle 7,in which the interposer security logic unit 128 transmits the encryptedpacket RX0 over the full-duplex link to the host. Upon receipt, the hostapplication 124 may un-shift the received data, for example by deletingNULL packets received from the interposer security logic unit 128. Insome embodiments, the un-shifted data may be processed transparently bydevice drivers or other software unaware of the interposer securitylogic unit 128. In such embodiments, it is assumed that the devicedrivers and other middleware do not perform any processing of data inclear. For such embodiments, the security is considered ‘transparent’(i.e., the device drivers are not aware of the security feature). Itshould be appreciated that, in other embodiments where the devicedrivers and other middleware processes data, the functionalities of thedevice drivers and other middleware need to be moved to a TEE in orderto process the data in clear.

Examples

Illustrative examples of the technologies disclosed herein are providedbelow. An embodiment of the technologies may include any one or more,and any combination of, the examples described below.

Example 1 includes a compute device for secure I/O data transfer, thecompute device comprising a processor to execute a trusted application;an input/output (I/O) device; and an I/O subsystem to establish asecured channel between the I/O subsystem and a trusted applicationrunning on the compute device; receive, in response to an establishmentof the secured channel, I/O data from the I/O device via an unsecuredchannel; encrypt, in response to a receipt of the I/O data, the I/O datausing a security key associated with the trusted application that is toprocess the I/O data; and transmit the encrypted I/O data to the trustedapplication via the secured channel, wherein the secured channel has adata transfer rate that is higher than a data transfer rate of theunsecured channel between the I/O device and the I/O subsystem.

Example 2 includes the subject matter of Example 1, and wherein toestablish the secured channel comprises to receive the security keyshared with the trusted application running on the compute device.

Example 3 includes the subject matter of any of Examples 1 and 2, andwherein to encrypt the I/O data comprises to encrypt, in response to areceipt of the I/O data, the I/O data using a security key.

Example 4 includes the subject matter of any of Examples 1-3, andwherein the I/O subsystem is further to receive encrypted configurationdata from the trusted application via the secured channel; decrypt theencrypted configuration data; and configure the secured channel based onthe decrypted configuration data.

Example 5 includes the subject matter of any of Examples 1-4, andwherein to configure the secured channel comprises to configure thesecured channel upon a power reset.

Example 6 includes the subject matter of any of Examples 1-5, andwherein the trusted application running inside a trusted executionenvironment (TEE) of the compute device.

Example 7 includes the subject matter of any of Examples 1-6, andwherein the secured channel is a full-duplex communication channel.

Example 8 includes the subject matter of any of Examples 1-7, andwherein to receive the I/O data comprises to receive, in response to anestablishment of the secured channel, I/O data via a communicationchannel between the I/O subsystem and the I/O device, wherein thecommunication channel is not encrypted.

Example 9 includes the subject matter of any of Examples 1-8, andwherein to transmit the encrypted I/O data comprises to transmitmetadata associated with the encrypted I/O data to the trustedapplication via the secured channel, wherein the data transfer rate ofthe secured channel is based on a size of the metadata.

Example 10 includes a method for secure I/O data transfer, the methodcomprising establishing, by the I/O subsystem of a compute device, asecured channel between the I/O subsystem and a trusted applicationrunning on the compute device; receiving, in response to establishingthe secured channel and by the I/O subsystem, I/O data from an I/Odevice via an unsecured channel; encrypting, in response to receivingthe I/O data and by the I/O subsystem, the I/O data using a security keyassociated with the trusted application that is to process the I/O data;and transmitting, by the I/O subsystem, the encrypted I/O data to thetrusted application via the secured channel, wherein the secured channelhas a data transfer rate that is higher than a data transfer rate of theunsecured channel between the I/O device and the I/O subsystem.

Example 11 includes the subject matter of Example 10, and whereinestablishing the secured channel comprises receiving, by the I/Osubsystem, the security key shared with the trusted application runningon the compute device.

Example 12 includes the subject matter of any of Examples 10 and 11, andwherein encrypting the I/O data comprises encrypting, in response toreceiving the I/O data and by the I/O subsystem, the I/O data using asecurity key.

Example 13 includes the subject matter of any of Examples 10-12, andfurther including receiving, by the I/O subsystem, encryptedconfiguration data from the trusted application via the secured channel;decrypting, by the I/O subsystem, the encrypted configuration data; andconfiguring, by the I/O subsystem, the secured channel based on thedecrypted configuration data.

Example 14 includes the subject matter of any of Examples 10-13, andwherein configuring the secured channel comprises configuring thesecured channel upon a power reset.

Example 15 includes the subject matter of any of Examples 10-14, andwherein the trusted application running inside a trusted executionenvironment (TEE) of the compute device.

Example 16 includes the subject matter of any of Examples 10-15, andwherein the secured channel is a full-duplex communication channel.

Example 17 includes the subject matter of any of Examples 10-16, andwherein receiving the I/O data comprises receiving, in response toestablishing of the secured channel, I/O data via a communicationchannel between the I/O subsystem and the I/O device, wherein thecommunication channel is not encrypted.

Example 18 includes the subject matter of any of Examples 10-17, andwherein transmitting the encrypted I/O data comprises transmitting, bythe I/O subsystem, metadata associated with the encrypted I/O data tothe trusted application via the secured channel, wherein the datatransfer rate of the secured channel is based on a size of the metadata.

Example 19 includes one or more machine-readable storage mediacomprising a plurality of instructions stored thereon that, in responseto being executed, cause a compute device to establish a secured channelbetween the I/O subsystem and a trusted application running on thecompute device; receive, in response to an establishment of the securedchannel, I/O data from the I/O device via an unsecured channel; encrypt,in response to a receipt of the I/O data, the I/O data using a securitykey associated with the trusted application that is to process the I/Odata; and transmit the encrypted I/O data to the trusted application viathe secured channel, wherein the secured channel has a data transferrate that is higher than a data transfer rate of the unsecured channelbetween the I/O device and the I/O subsystem.

Example 20 includes the subject matter of Example 19, and furtherincluding a plurality of instructions that in response to being executedcause the compute device to receive encrypted configuration data fromthe trusted application via the secured channel; decrypt the encryptedconfiguration data; and configure the secured channel based on thedecrypted configuration data.

What is claimed is:
 1. A computing device comprising: a processor toexecute a trusted application; an input/output (I/O) subsystem circuitrycoupled to the processors, the I/O subsystem circuitry to: receive asecurity key shared with the trusted application running at thecomputing device; receive encrypted configuration data from the trustedapplication via an established secured channel relating to the trustedapplication; decrypt the encrypted configuration data; and configure theestablished secured channel based on the decrypted configuration data.2. The computing device of claim 1, wherein the I/O subsystem circuitryis further to receive encrypted packet defining initializationparameters for I/O data transferred from an I/O device.
 3. The computingdevice of claim 1, wherein the initialization parameters include one ormore of a packet size, a header size, a header format, or controlinformation relating to the I/O data transfer from the I/O device,wherein the initialization parameters are not shared with the I/Odevice.
 4. The computing device of claim 1, wherein the I/O subsystemcircuitry is further to configure the secure channel upon power reset.5. The computing device of claim 1, wherein the secure channel isestablished between the I/O subsystem circuitry and the trustedapplication, and wherein the I/O subsystem circuitry hosts imposersecurity circuitry.
 6. A method comprising: receiving, by aninput/output (I/O) subsystem circuitry, a security key shared with thetrusted application running at a computing device; receiving, by the I/Osubsystem circuitry, encrypted configuration data from the trustedapplication via an established secured channel relating to the trustedapplication; decrypting, by the I/O subsystem circuitry, the encryptedconfiguration data; and configuring, by the I/O subsystem circuitry, theestablished secured channel based on the decrypted configuration data.7. The method of claim 6, further comprising receiving, by the I/Osubsystem circuitry, encrypted packet defining initialization parametersfor I/O data transferred from an I/O device.
 8. The method of claim 6,wherein the initialization parameters include one or more of a packetsize, a header size, a header format, or control information relating tothe I/O data transfer from the I/O device, wherein the initializationparameters are not shared with the I/O device.
 9. The method of claim 6,further comprising configuring, by the I/O subsystem circuitry, thesecure channel upon power reset.
 10. The method of claim 6, wherein thesecure channel is established between the I/O subsystem circuitry andthe trusted application, and wherein the I/O subsystem circuitry hostsimposer security circuitry.
 11. At least one computer-readable mediumhaving stored thereon instructions which, when executed, cause acomputing device to perform operations comprising: receiving, by aninput/output (I/O) subsystem circuitry, a security key shared with thetrusted application running at the computing device; receiving, by theI/O subsystem circuitry, encrypted configuration data from the trustedapplication via an established secured channel relating to the trustedapplication; decrypting, by the I/O subsystem circuitry, the encryptedconfiguration data; and configuring, by the I/O subsystem circuitry, theestablished secured channel based on the decrypted configuration data.12. The computer-readable medium of claim 11, wherein the operationsfurther comprise receiving, by the I/O subsystem circuitry, encryptedpacket defining initialization parameters for I/O data transferred froman I/O device.
 13. The computer-readable medium of claim 11, wherein theinitialization parameters include one or more of a packet size, a headersize, a header format, or control information relating to the I/O datatransfer from the I/O device, wherein the initialization parameters arenot shared with the I/O device.
 14. The computer-readable medium ofclaim 11, wherein the operations further comprise configuring, by theI/O subsystem circuitry, the secure channel upon power reset.
 15. Thecomputer-readable medium of claim 11, wherein the secure channel isestablished between the I/O subsystem circuitry and the trustedapplication, and wherein the I/O subsystem circuitry hosts imposersecurity circuitry.